Estimations in Agile Environments — Why, When and How to use it
Estimating is a very common concept in Agile, especially in Scrum teams, which usually estimate their product backlog and sprint backlog. Estimating as a concept makes quite a lot of sense, without it life would be pretty hard and surprising.
How many trees are in the picture? How many leaves?
Estimating can be hard. Why, when and how should it be done?
Estimations are done and used in many different situations. How long will something take? How much will it cost? When will it be ready? What will bring the most value with the money I have?
Estimation is not about getting the exact answers, but answers that are good enough. Creating an understanding of what result an action or decision will lead to is important, especially in business life. And why is this?
Why Estimate
Estimations can save time and money. They can give answers to when something can be delivered, how much can be delivered and how much resources would be needed.
It also helps in prioritizing work and in making decisions. Even if something would bring a lot of value, developing it might not be valuable if it takes way too much time.
The tricky part with estimates is that quite often, especially in business life, estimations are treated as exact numbers or promises. I’ve experienced too many times at my work as a consultant, that team’s estimations have gone wrong and afterward, management sits in meetings pondering about why this happened. Understandable, as usually a lot of money is involved.
But in that case, we’ve missed the root cause for the challenges and are focusing on wrong things that will just generate waste.
Therefore, it’s important to think about how estimations are done, when and what units to use.
But first, we must acknowledge, that estimations should be treated as estimations. Estimations are done because we don’t know how long something will take and even if it includes calculation, it does not mean that it can be taken as given. If we already know how long something will take, then it's not an estimate.
To guess or calculate the cost, size, value, etc. of something
Estimation Meaning in the Cambridge English Dictionary
Estimations can bring value, support decision making, help in prioritizing and give predictability. But they can also be big pain points in organizations and cause a lot of waste.
So, when should we estimate and how should it be done?
Product Backlog
The product backlog contains different types of work and functionalities desired by the product. There are a few good reasons for estimating the product backlog.
It helps teams to make predictions about how much can be delivered and when.
It aids in prioritizing work. Especially product owners (and managers) will find it beneficial.
Risk management and fewer surprises. Teams become more familiarized with upcoming work if they have so much knowledge about the requirements that they can do actual estimations.
Let’s say then that you should estimate the backlog for a year or one quarter. These kinds of estimations can help in decision-making and resourcing. Should a project be started or not? What are the priorities? Do we need more people?
Note that the more exact you try to be with your estimations, the bigger the risk that the estimate will be inaccurate. Trying to give very specific estimations for a lot of work is also very time-consuming. Trying to estimate a project in hours or days might be very inaccurate if the requirements are not known.
Hence, it doesn’t make sense to estimate hours or days for long periods. It’s better to use story points or T-shirt sizes instead. This will give an idea about the future workload and the type of work. Are there big, time-consuming features in the backlog? Or maybe there are many small tasks that need to be worked on? What kind of expertise would the team need for upcoming work?
Sprint Backlog
The sprint backlog consists of tasks that the team will complete during a sprint. Estimating the sprint backlog brings value because
It helps to determine how much work to bring to the sprint
It identifies different tasks and estimating them helps in coordinating the work
When estimating the sprint backlog, it makes more sense to use hours or days compared to using these units for the product backlog. The sprint is much shorter and contains fewer items, so being more specific is acceptable. Note that it’s not a must, but something that can be done.
Estimating the workload for a sprint will help the team in planning. The team plans who will work on what items, see if there are some dependencies and the team can assess the workload. As the timeframe is shorter, it makes sense to be a bit more accurate with the estimations.
When To Not Estimate
Estimations should not be done if the work is way too big anyway. If the requirements are unknown, you must first invest time in understanding what is needed for the feature. Only then is there any reason to estimate. Otherwise, it’s just guessing, which is not the same thing as estimating.
There is usually no need for estimates if the team is very mature and the product itself is already established, mature and predictable. Additionally, if the team is in a flow of predictability and the product is in a repeatable cycle of life estimations can be a waste of time.
It’s good to remember that even though how accurate estimations would seem, they’re still estimates. They’re not deliverables nor a velocity. Not a promise. Not a fact. As stated at the beginning of this article, estimation happens when we don't know exactly how long something will take. If estimations are considered as a process for improving communication and sharing understanding, then we're on the correct path.
Estimates are not a waste if done correctly. We just need to think a bit about how we do them, when and why.
Citations
Dictionary, e. (2022). Estimation Meaning in the Cambridge English Dictionary. [online] dictionary.cambridge.org. Available at: https://dictionary.cambridge.org/dictionary/english/estimate [Accessed 7 Jan. 2022].